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(54) Managing calls over a data network 

(57) A method and system of managing calls over a 
data network (20) Includes determining an available 
bandwidth of the data networlt (20). After a call request 
is received for establishing a call between at least two 
network terminals (14. 16, 30),QneormoreofapluiHllty 
of resource elements are selected In response to the 
call request based on the bandwidth of the data network 
(20). The resource elements, which can include codecs 
(coders/decoders), packet sizes (for carrying audk> da- 
ta), and others, are used in the requested call between 



the at least two networl^ lemiinals (14. 16, 30). Further, 
a plurality of communities (402, 404, 406) may be de^ 
fined each including one or more temninals. One or more 
usage threshold values may be assigned to a link or 
finks (430, 432) between communities (402, 404. 406), 
and a call request Is processed based on the one or 
more usage threshold values. The processing Includes 
at least one of determining whether to admit the call re- 
quest and selecting resource elements to be used dur- 
ing a call between terminals over the link (430, 432). 
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Oescriptfon 
Background 

[0001] The inventbn relates to managing calls over a 
data network, such as an Internet Protocol (IP) network. 
[0002] Packet-based data networks are widely used 
to fink various nodes, such as personal connputers, serv- 
ers, gateways, and so forth. Packet-based data net- 
works include prfvate networks, such as.local area net- 
works (LANs) and wide area networks (WANs), and 
" PuWia networksr such-ae-the-lntemetrTheHncreased 
availability of such data networks has Increased acces- 
sibility annong nodes, whether the nodes are located in 
close proximity to each other (such as within an organ- 
izatfon) or at far distances from each other. Popular 
forms of communications across such data networks in- 
clude electronic mail, file transfer, web browsing, and 
other exchanges of digital data. 
[0003] With the Increased capacity and reliability of 
data networks, voice communicattons over data net- 
works, includhg private and public networks, have be- 
come possible. Voice communications over packet- 
based data networks are unlike voice communicattons 
in a conventional public switched telephone nehirork 
(PSTN), which provkles users with dedicated, end-to- 
end circuit connectfons for the duratton of each call. 
Communfealions over data networks, such as IP (Inter- 
net Protocol) networks, are perfomied using packets 
that are sent In bursts from a source to one or nrwre des- 
tination nodes. Voice data sent over a data network has 
to share the network bandwidth with conventional non- 
voice data (e.g., electronic mail, file transfer, web ac- 
cess, and other traffic). One standard that has been im- 
plemented for communtoatlone of vok:e as well as other 
data is the H.323 recommendation from the Telecom- 
munication Sector of the International Telecommunrca- 
tion Unbn (ITU-T), which describes terminals, equip- 
ment and sen^tces for multimedia communications over 
packet-based networks. 

[0004] In an IP data network, each data packet is rout- 
ed to a node having destrnatton IP address contained 
within the header of each packet. Data packets may be 
routed over separate network paths before arriving at 
the final destinatton for reassembly. Transmfesten 
speeds of the various packets may vary widely depend- 
ing on the usage of data networks over which the data 
packets are transferred. During peak usage of data net- 
works, delays added to the transfer of voice data pack- 
ets may cause poor perfonrance of vofce communica- 
tions. Voice data packets that are lost or delayed due to 
Inadequate or unavailable capacity of data networks or 
resources of data networks may result in gaps, silence, 
and clipping of audio at the receiving end. 
[00(^ A needthus exists for an Improved methodand 
system to manage the quality of voice calls or other au- 
dio communicattons over data networks. 



Summary 



[0006] In general, according to one embodiment, a 
method of managing calls over a data network includes 
s determining usage information of the data network. A 
can request is received for establishing a call between 
at least two network terminals. One or more of a plurality 
of resource elements are selected as candidates for use 
in the requested call in response to the call request 
10 based on usage Infonnation of the data network. 

[0007] In general, according to another embodiment, 
* * 3-method-ofTnanaging-calls in~a1etephony-sy5tem" in-"' 
eludes defining a plurality of communities each including 
one or more communication endpoints and assigning 
« one or more usage threshold values to a link between 
communities. Further, a call request is processed based 
on the one or more usage threshold values. The 
processing includes determining whether to admit the 
can request over the link. 
^ [0008] Some embodiments of the invention may pro- 
vide one or more of the following advantages. Resource, 
elements can be selected to optimize quality of service 
while at the same time taking into account the usage of 
the data network as well as usage of other transmission 
2^ or communfcations resources. Proper selection of re- 
source elements as well as call admission control re- 
duces the likelihood of overburdening links between ter- 
minals. As a result, the likelihood of delays in the com- 
municatton of audio data that may lead to vartous audio 
30 distorttons Is also reduced. By efHciently using packet- 
based data networks for telephony and other forms of 
audio convnunicattons. sharing of such data networks 
for carrying audio data (which are relatively time sensi- 
tive) and traditional fomis of digital data (such as elec- 
ts tronfc mail traffic, file transfer traffic, and other traffic) 
can be made more effective. 
[0009] Other features and advantages will become 
apparent from the foltowing description and from the 
claims. 

40 

Brief Description Of The Drawings 



[0010] Figs. 1A-1B are block diagrams of an embod- 
iment of a telephony communications system in which 
^ voice or other audio cteita may be communicated over 
packet-based data networks. 
[0011] Fig, 2 Illustrates the flow for processing a call 
request between an origination temriinal and a destina- 
tion terminal in accordance with one embodiment. 
so [0012] Fig. 3 Is a flow diagram of tasks performed by 
a call server in response to a call request In accoidance 
with one embodintent. 

[0013] Fig. 4 illustrates the flow for processing a call 
request between an origination tenmlnal and a destfna- 
ss tlon tennlnal In accordance with an alternative embodi- 
ment. 

[0014] Fig. 5 is a flow diagram of tasks perfomied by 
a call senrer in response to a call request in accordance 
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with the alternative embodiment. 
[0D15] Fig. 6 illustrates components in a temiinal and 
call sender of Figs. 1 A-1 B. 

[001 6] Figs. 7A-7B Illustrate E-model charts that map 
conditions of a network link to a desired quality of sen^ s 
In accordance with an embodiment 
[001 7] Fig. 8 illustrates a flow for processing a call re* 
quest in accordance with an embodiment that utilizes 
the E-model charts of Figs. 7A-7B. 
[0018] Fig. 9 illustrates a telephony communications io 
system that includes a plurality of communities and links 

"-between-the-commorriltes-over-which-call- admission 

control Is performed In accordance with an embodiment. 
[0019] Figs. 1 0A-10B Illustrate the flow for managing 
a call request between terminals in different communi- is 
ties of Fig. 9. 

Detailed Desortption 

[0020] In the following description, numerous details 20 
are set forth to provide an understanding of the present 
invention. However, it will be understood by those skilled 
in the art that the present inventk^n may be practbed 
without these details and that numerous variations or 
modtflcatk>ns from the described embodiments may be 2$ 
possible. For example, although the description refers 
to telephony communications over data networks, cer- 
tain aspects of the methods and apparatus described 
may be advantageously used with other types of com- 
munk:atk>n8 systems, such as those convnunlcating 3o 
Video or multimedia data (for vkieo conferencing, for ex- 
ample). 

[0021] Referring to Figs. 1 A and 1 B, one embodiment 
of a telephony communteattons system 10 includes a 
number of end^lnts or terminals (terminals 1 4. 1 6, and 3S 
30 Illustrated) that are capable of performing voice or 
other audk> communications over a packet-based or 
message-based data network 20. As used here, teleph- 
ony communications* refers to the tiansmisslon and re- 
ceipt of sounds (e.g., voice or other audio signals) be- 4o 
tween different points In a system using either wireline 
or wireless links. Example terminals 14, 16. and 30 may 
include computer systems with speech capability, tele- 
phone units thai Include interfaces to the data network 
20, gatewayscoupledtostandardtelephone&34though 4S 
a public switched telephone network (PSTN) 32, and 
other types of communk^ation devices. Telephony com- 
munications can occur between any two or more termi- 
nals over the data network 2b. 

[0022] The data network 20 may include, as exam- so 
pies, private networks such as intranets (e.g., k)cal area 
networks and wkJe area networks), and public networks 
such as the Internet. More generally, as used here, a 
data network is any communications network that utiliz- 
es message-based or packet-based communications, ss 
In one embodiment, the data network 20 communicates 
according to the Internet Protocol (IP), as described in 
Request for Comment (RFC) 791. entitled "Internet Pio- 



tocol,* dated September 1 981 . The data network 20 may 
include a single network or link or multiple networks or 
links that are coupled through gateways, routers, and 
the like. 

[0023] In one embodiment, a call sender 1 2 Is coupled 
to the data network 20 to manage telephony communi- 
cations (e.g.. call setup, processing, and temiinatwn) 
between or among the tenninals 14, 16. and 30 (and 
other terminals). A policy server 18 may be accessible 
by the call sewer 12 to determine usage policy for te- 
lephony communlcattons over the data network 20 to 
contn3fthexiualityx5fservice-ontherdataTretwork^0.-1=or*- 
example, the poltey sender 18 may set the telephony us- 
age of the data network 20 for different time periods. 
During periods of expected high traffic (e.g.. business 
hours), policy server 18 may set a low usage target for 
telephony communfcations. On the other hand, during 
periods of low expected traffic, the target usagsof the 
data network 20 for telephony communlcatk>ns may be 
set higher. 

[0024] Additionally, a network monitor system 1 9 may 
be coupled to the data networt< 20 to monitor certain 
characteristbs and conditbns of one or more portbns 
of the data network 20. TTie characteristics and condi- 
tions monitored may include packet delays, jitter, and 
packet tosses. Packet delay refers to a delay experi- 
enced in transmission due to high traffic or other condi- 
tions. Packet loss refers to the percentage bss of pack- 
els. Jitter refers to variations in the delay of different 
packets In the same transmissbn. Jitter may contribute 
to delay on a network link since receiving platforms need 
to buffer the received data packets to lake into account 
the different delays of packets. 
P025] Although only one call server and policy server 
are Illustrated, multiple call servers and policy servers 
roay be coupled to the data networi<. In this arrange- 
ment, each of the multiple call servers may be respon- 
sible for managing call requests from a predetermined 
group of terminals, and each polk^y server may be re- 
sponsible for maintaining usage policy for different por- 
tions of the data network 20. Further, more than one net- 
work monitor 1 9 may be included in the telephony com- 
munlcatbns system 10. For example, multiple networic 
monitors may be located to enable monitoring of char- 
acteristics and conditions of different portions of the data 
network 20. A call sen/er. policy sen/er, and network 
monitor may be implemented on separate platfomrts or 
in the same platform. 

[0026] To establish a call between two or more termi- 
nals for performing telephony communications, a call re- 
quest Is sent from an origination terminal to the call send- 
er 12 for processing. The call request includes the IP 
address of the orlglnatten terminal, the directory number 
of the destination terminal, and a list of one or more re- 
source elements supported by the origination terminal 
to be used during an established call. A terminal may 
be relatively busy at the time a call Is desired As a result . 
processing capability and storage capability in the orig- 
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Ination terminal may be limited so that resource ele- 
ments that require high bandwidth are not Indicated as 
being supported. Examples of resource elements in- 
clude codecs (coders/decoders), the size of packets 
carrying audio data, and other resource elements, as 
explained further below. 

[0027] By querying the policy server 1 8, the call server 
1 2 determines the usage policy for the data network por- 
tions over which the call will be established and discards 
any resource elements that may be inconsistent with 
that poRcy. Additionally, the call sender 12 can further 
— restrictusfrofresourceelements-basedonactaafusage- 
of transmission resources. Thus, for example, if a rela- 
tively large number of calls have been placed through 
the call server 12» the types of resource elements that 
may be empkjyed tor further calls may be those that 
have relatively low bandwidth requirements. Thus, the 
call server 12 is able to manage call requests based on 
usage infomnatbn, including usage policy and/or actual 
usage of the data network 20. 
[0028] Optionally, according to some embodiments, 
the call server 12 may also query the network monitor 
19 to determine the current characteristics and condi- 
tions of the network. Selection of resource elements 
may thus further be based on the cun-ent characteristics 
and conditions of the network (e.g., delays being expe- 
rienced by packets and percentage of packet k)ss). 
Next, the call senrer 1 2 ranks the remaining supportable 
resource elements based on predetemiined merit at- 
tributes, which may include quality of servtee, the avail- 
able bandwidth, expected usage of transmisskxi re- 
sources, and other attnbutes. Selection of the resource 
elements to use for a particular call Is based on the rank- 
ing performed by the call server 12. 
[0029] One type of resource element is the audk> cod- 
er/decoder (codec) used by each of the terminals in- 
volved in a call session. An audio codec encodes audio 
signals originating from an audio input device (e.g., mi- 
crophone) for transmission and decodes received audio 
data lor output to an output device (e.g., a speake^. The 
codec can be implemented In software. Several types 
of codecs are available that have varying levels of data 
compressk)n and data transfer rate requirements. For 
example, the Q.711 codec provides uncompressed 
communicatbns of voice data, but has a data transfer 
rate requirement of 64 kbps (kilobits per second) in each 
direction. Other codecs, such as the G.728. G.729A, G. 
729, G.723.1 , and Q.722 have varying compressbn al- 
gorithms and data transfer rate requirements (which are 
tower than that of the G.711 codec). The listed G series 
of audio codecs are recommendatbns from the Interna- 
tional Telecommunication Union (ITU). Other types of 
codecs may be supported by temilnals In further em- 
bodiments. 

[0030] Generally, higher compresston leads to a re- 
duced amount of data so that data transfer rate require- 
ments over a link may be reduced. However, because 
compresskxi of data may cause loss of information, au- 
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dio quality may be adversely affected. Thus, the two ob- 
jectives of higher quality audw and lower data transfer 
rate requirements may conflict. 
[0031] Conventionally, an originatksn terminal that de- 
sires to establish a voice communlcatkNi with a destina- 
tion tenminal sends a list of supported codecs to the des- 
tinatk>n terminal. In response, the destination terminal 
chooses an acceptable codec from the list. Such a proc- 
ess is provided by the H.323 protocol, which is a recom- 
mendation for packet-based multimedia communica- 
tions systems from the ITU-T Although such a process 
allows-vofce-commonications -employing a commonly 
supported codec between the origination and destina- 
tion terminals, it does not take into account the capacity 
and usage of the link and other transmission resources 
between the terminals. In this case the data network 20, 
as well as other transmission or communications re- 
sources. 

[0032] Another resource element Is the networic pack- 
et size supported by the codec to communksate votee or 
other audk). As used here, network packet size refers 
to the size of the networic packet used to carry audk> 
data In one embodiment, the packet includes an IP 
packet, which includes an IP header and IP payload. In 
further embodiments, other types of network packets 
may be emptoyed. depending on the type of the data 
network 20. Inside the IP paybad may be a TCP (Trans- 
mlsston Control Protocol) or UDP (User Datagram Pro- 
tocol) packet A TCP or UDP packet includes a header 
and payload. For telephony communications, the pay- 
load of a UDP packet may include an RTP (Real-Time 
Transmission Pnstocol) packet. RTP Is a protocol for the 
transport of real-time data, nicluding audio and video. 
An RTP packet Includes an RTP header and an RTP 
payload, which can carry one or more frames of audio 
data, TCP is described In RFC 793, entitled Transmis- 
sion Control Protocol,* dated September 1981. UDP Is 
described in RFC 768, entitled 'User Datagram Proto- 
col." dated August 1980. RTP is described in RFC 1889, 
entitled "RTP: A Transport Protocol for Real-Time Ap- 
plications,' dated January 1 996; and RFC 1890, entitled 
"RTP Profile for Audio and VWeo Conference with Min- 
imal Control," dated January 1996. 
[0033] A frame refers to the duration of a speech sam- 
ple. For example, a frame r^ay be 10 milliseconds (ms); 
vrfilch indicates that a 10-ms sample of speech is con- 
tained in the frame. Other frames include 20 ms, 40 ms, 
and so forth, samples of speech. Each type of codec 
can support certain frame sizes. The number of frames 
that is placed into an RTP payload detemilnes the size 
of the network packet (e.g., IP packet or other type of 
packet) used to cany the audio data. During a given call 
ses8k>n, the number of frames to be carried In a networic 
packet can be selected. The networic packet size has 
implk^tions on the burden placed on the data networic 
in a given call session. Smaller networic packets gener- 
ally are associated with higher cyvertiead, eince more au- 
dio ciata packets are communicated over the data net- 



10 



IS 



20 



2B 



30 



3S 



40 



46 



4 



7 



EP1079 573A2 



8 



work 20 between tennfnafs. Larger network packets are 
associated with reduced overhead, but come at the cost 
of kmger delays since a longer speech sample is creat- 
ed between successive transmissions of audio over the 
data network 20. Thus, selection of netwbrk packet size b 
(as determined by the selection of the number of frames 
to be carried in the packet) may also lead to a conflict 
between the objectives of higher quality audio and re- 
duced k>ad on the data network 20 and other transmis- 
sion resources. w 
[0034] in accordance with some embodiments, a call 
— contfoi-mechanismimplemented'trlhe-teT mi na ls r c all- 
sen^er(s). policy server(8), and/or network monltor(8) of 
the telephony communications system 10 balances the 
need for high audto quality as well as the need to reduce is 
burden on the data network 20 and other transmission 
resources. The call control mechanism selects a sup- 
ported codec, network packet size, and^or other re- 
source element that takes Into account support for the 
resource element by all communicating terminals, the so 
available capacity of the data network 20 and other 
transmission resources* and the objective to achieve the 
highest possible quality of $ervk:e. Additional or different 
criteria may be used in other embodiments. 
[0035] An origtnatfon temiinal communicates with the 2S 
call sender 12 over the data network 20 for call control 
signaling (to set up and tenminate a call). After a con- 
nection is established between terminals over the data 
network, the temiinals oommunicate media traffic (voice 
or other audb) and media traffic signaling with each oth- 3o 
er through the data network 20. The call server 12 per- 
forms call setup processing, which includes translation 
of dialed digits (such as 10-digit telephone number) to 
an IP address of a destinatton temiinal. The call server 
12 also keeps tracks of the status (e.g., busy, kjie, down, 3S 
and so forth) of the terminals that it is responsible for I n 
additfon, the call sender 12 keeps track of the usage of 
the transmission facility (the data network 20 and other 
transmisekxi resources) by the telephony application. 
As used here, telephony applk^tion" refers to one or 40 
more sessions of voice or other audio communlcattons 
between or among the various terminate. 
[0036] Referring to the examples of Rgs. 2-5, proo 
esses for establishing a call between an origination ter- 
minal (e.g., the tennlnal 14, also referred to as terminal 
P1 ) and a destination temitnal (e.g., th e tenninai 1 6, also 
refered to as terminal R2):are Illustrated. In the embod- 
iments of Figs. 2-6, the call sender 12 does not acc&ss 
the network monitor to select resource elements. An 
embodiment which does is described in connectton with so 
Figs. 7A-7B and 8. 

[0037] Fig. 2 illustrates the messages communicated 
between the various entities Involved in call establish- 
ment, and Fig. 3 illustrates the tasks performed by the 
call server 12 In the call establishment process accord- ss 
ing to one embodiment. To start a call, the orlginatton 
tenninai 14, which has an IP address Pi , sends a call 
request, such as a Cafl.Setup message, which Is re- 



ceived (at 102) by the call server 12. The CalLSelup 
message includes a number identifying the destination 
terminal, a codec list including the codecs that are sup- 
ported by the terminal 14, a list of supported packet siz- 
es, arKi^or a list of other supported resource elements. 
Supported packet sizes are determined by the number 
of frames and the size of each frame (e.g., 1 0-ms frame 
20-ms frame, and so forth). Example codecs that are 
supported include G.711. G.728, G.729, G.729A. G. 
723.1, and G.722 codecs. The G.711 codec communi- 
cates uncompressed audio data and requires a 64-kbps 
data transfer fatsrwhgr8agthg"gth er codecs pro vide " 
varying levels of data compression with lower data 
transfer rate requirements. For example, the G.728 co- 
dec requires a 16-kbps transfer rate, the G.729 codec 
requires an 8-kbps transfer rate, and the G.723. 1 codec 
requires a transfer rate of 6.3 kbps, 5.3 kbps, or less. 
piOOB] In the call sender 1 2. the list of available codecs 
and list of supported packet sizes in the Call_Setup 
message are received (at 104) and combined intoacan- 
dkiate list. Alternatively, the different lists of resource el- 
ements may be maintained as separate candidate lists. 
[0030] Based on the CalLSetup message, the call 
server 12 translates (at 106) the number (e.g., the dialed 
nunr^ber) of the called party into an IP address (e.g.. ad- 
dress P2 of the destination temninal 16). Next, the call 
sender 12 sends (at 107) a query message to the policy 
sewer 18. The query message includes the IP address- 
es of the origination and destination temiinais (PI, P2) 
and a request for the usage policy for a telephony ap- 
plication between the pair of temiinals at the present 
time. 

[D040] The polfcy server 1 8 responds to the query by 
sending a reply message back to the call server 12 to 
indicate the usage policy for the temninals PI and P2 for 
the present call session. The usage policy information 
may be In the form of predetermined values represent- 
ing different levels of target usage for telephony com- 
munications. Alternatively, the usage policy Information 
may be in the forni of information identifying resource 
elements that are supported or not supported at the 
present time. Based on the received usage policy bifor- 
nation, the call server 1 2 updates (at 1 08) the candidate 
list by deleting unacceptable codecs. The policy server 
18 may set a low usage level for the telephony applica- 
tion because of high traffic carrying traditional data 
packets.(e.g., e-mail traffic, web browsing traffic, file 
transfer traffic, and so forth). Thus, codecs that have 
high bandwidth requirements may be deleted (at 108) 
from the candidate list. Examples of such high band- 
width codecs include the G.711 codec. In additicffi, un- 
acceptable packet sizes are also deleted from the can- 
didate list (at 108). depending on the usage polk)y If kjw 
usage level is indicated, then shorter packet sizes may 
be deleted from the list Thus, the call eerver 12 selects 
one or more resource elements (e.g., codecs and pack- 
et sizes) that are supported based on the usage polk:y 
of the data network 20. 
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[0041] Optionally, the call server 1 2 can also perform 
an SKlditional bandwidth restriction based on the usage 
of transmission resources. Each connection between a 
pair of tenninals shares a pool of transmission resourc- 
es (links coupling the terminals that the call server 12 is 5 
responsible for, routers and gateways coupling the links, 
and other resources) with other appllcattens. The call 
server 12 keeps track of the usage of the pool of trans- 
mission resources by tracking the number of voice calls 
and bandwidth usage. When the usage reaches a pre- io 

delemiined threshold, thecall sender 12 may further limit 

theiiandwldthTJsage.-T^cairsBrvBr^^TnayiJS^ 
llmltatk>ntofurthordelete (at 110) unacceptable codecs, 
packet sizes, and other resource elements from the can- 
didate list so that a further reduced number of resource is 
elements may be selected. 

[0042] The call seiver 12 then sends (at 112) a query 
message, e.g., a Query_Resource^vailabllity mes- 
sage, to the destination temiinal P2 to fcJentify the sup- 
ported codecs, packet sizes, and other resource ele- so 
ments In the destination temiinal P2. The results are re- 
turned In a Reply_Resource_AvailabiIity message, from 
which the call server 12 can determine the codecs, 
packet sizes, and other resource elements supported 
by the destlnatbn temiinal P2. The candidate list of co- ^ 
decs, packet sizes, and other resource elements is up* 
dated based on the available codecs In the destination 
terminal P2, with unsupported codecs, packet sizes, 
and other resource elements deleted from the candidate 
list. 00 
[0043] Potentially, all codecs or packet sizes may 
have been deleted from the candidate list. If either the 
list of codecs or the list of packet sizes is empty (as de- 
termined at 114), then no supported codec or packet 
size exists to allow a call to proceed between the termh 3S 
nals PI and P2. at which point the call server 1 2 sends 
(at 1 16) a message to temriinate the calf setup. The call 
sender 1 2 also informs the origination terminal PI <rf the 
setup failure. 

[0044] If at least one codec and at least one packet 40 
size IS available In the candidate list, then the call can 
proceed. If two or more codecs are present in the can- 
didate list, then the codecs are reordered (at 118) by 
applying a merit-based codec ranking algorithm to rank 
the codecs in the candidate list in the descending merit 4$ 
order (described further below). Packet sizes may aiso 
be ordered according to a merit ranking algorithm, as 
may other resource elements. The codec, packet size, 
and other resource element having the highest relative 
rank is selected. Alternatively, selection may be per- so 
formed by the terminals, which may be adapted to select 
the highest ranking resource elements from a list. 
[0045] Next, the call server 12 sends a CalLSetup 
message to the destinatbn lemnlnal P2, with the 
CalLSetup message including an Mentiflerof thecalling ss 
party (either the calling terminal's telephone number or 
its IP address), the selected codec, packet size, and oth- 
er resource element The call sender 12 then proceeds 



(at 122) to the remaining tasks to be performed in the 
can setup, Including sending a Selected_Resource 
message identifying the selected codec, packet size, 
and other resource element back to the originatfon ter- 
minal PI . Alternatively, the codec, packet size, and oth- 
er resource element may be communicated as param- 
eter in a Setup_Connection mesrage sent by the call 
sender 1 2 to connect the call between temilnate PI and 
P2. A media path Is then set up between the terminals 
PI and PZ 

[0046] Although reference is made to selection of sev- 
-^THlTeBgoi^g-gtefftffl^ts: - 
embodiments may select fewer than all the possible 
types of resource elements in the call management 
process. For example, call sender 12 may perform se- 
lection of only codecs to manage bandwidth usage and 
quality of service on the data network 20. In addition. If 
multiple call servers are present in the data network 20, 
then communications may occur between call sen/ers 
to enable selection of resource elements for establish- 
ing a call between terminals controlled by the call send- 
ers. 

[0047] Ref emng further to Figs. 4 and 6. another em- 
bodmient of performing call establishment in whteh a co- 
dec, packet size, and/w other resource element are se- 
lected is Illustrated. Fig. 4 illustrates messages ex- 
changed among the entitles involved In the call estab- 
lishment, and Fig. 6 Illustrates the tasks performed by 
the cad sewer 12 in accordance with this embodiment. 
The tasks perfomied in the embodiment of Fig. 5 that 
are common to the tasks performed In the embodiment 
of Fig. 3 have the same reference numbers. As with the 
Figs. 2-3 embodiment, the originatton terminal PI sends 
a CalLSetup message to the call sender 1 2 that includes 
a list of available codecs, a list of packet sizes, and a 
list of other resource elements, which are received In a 
candklate list (at 104) and updated (at 108) based on 
the usage polk:y in the data network20forthe telephony 
applkjalton as determined from the policy .server 18. 
This candklate list may further optionally be updated 
based on an Internal table In the call sen/er 12 on the 
usage of transmission resources (at 110). However, in- 
stead of querying the destinatton tenminal P2 for its 
available codecs and supported packet sizes, the call 
server 12 In this alternative embodiment determines (at 
202) if the candidate list is empty at this point. If so, then 
a capable codec and packet size have not been found 
and the call setup is temilnated (at 204). However, If the 
candklate list includes at least one codec and at least 
one packet size, the call sender 12 reorders (at 206) the 
codecs and packet sizes (if more than one of each) in 
the candidate list according to a descending merit score. 
The candidate list is sent (at 208) by the caller sender 
12 to the destination tennlnal P2 in a CalLSetup mes- 
sage to notify the destination tenri inal P2 of an Inccxning 
call. At this point, the destination terminal P2 may com- 
pare the list of its supported codecs to the ones in the 
candidate list. The destinatk»i terminal P2 selects the 
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codec (and other resource elements) having highest rel- 
ative rankffig from the candidate list that is also currently 
supported by the terminal P2 for the current call. If no 
capable codec or packet size exists, the destination ter- 
minal P2 infonme the caO 8en^er12 of the rejection. The 
call server 12 detemiines (at 210) if a capable codec 
and paclcet size has been identified. If not (as deter- 
mined from receipt of the rejectbn message from the 
destination terminal P2). the call setup is tenninated (at 
212). 

[0048] However, tf a capable codec and packet size 
— are-identifiedrthe-destinatton-termfnal-P2-infonTis-1he- 
call sender 12 erf the selected codec through a 
Call^Progress message or some other message. If the 
call server 12 determines that a capable codec and 
packet size have been selected, then the call server 12 
transmits the selected codec and packet size (at 214) 
to the origination temiinal PI in a Setup.Connection 
message or some other message, such as a 
Select.Resource message. The call sender 1 2 then pro- 
ceeds to the remaining tasks to perform for the call setup 
(at 216), after which a media path is established be- 
tween the origination terminal PI and the termination 
temiinal P2 for voice (or other audio) communications. 
[0049] Variations of the processes described in con- 
nection with Figs. 2-5 may be performed periodically 
during a call session between two or more termhals. 
This allows modrficatron the selected resource ele- 
ment in response to Increases or decreases in the avail- 
able bandwkfth of the data network 20 and other trans- 
mission resources, including usage of resources in the 
terminals themselves. 

[0050] Referring to Fig. 6, components of an example 
tenminal and call server are Illustrated. In Fig. 6. the com- 
ponents of the terminal 14. 16. or 30 and call sender 12. 
are illustrated. As noted atK)ve, the tenminal 14, 16, or 
30 can be one of many types of devtees capable of com- 
municating vok:e over the data network 20. These ter- 
mhals may include computer systems, telephones that 
are configured to communicate over a data networic, a 
gateway system to the public switched telephone net- 
work (PSTN), and other communications devices. 
[0051] The layers of the terminal 14, 16. or 30 include 
a networi( interface controller 302 that is coupled to the 
d&ta network 20. Above the networic interface controller 
302 Is a network device driver 304 and a network stack 
306, such as a TCP/IP or UDP/IP stack. Above the net- 
woric stack 306 is an RTP layer 308 that perfomfis vari- 
ous tasks associated with real time communicatbns 
such as telephony communteations. Incoming data from 
the data network 20 is received through the layers 302, 
304. 306 and 308 and routed to an audio codec 310, 
whksh has been selected from a number df available Co- 
decs as discussed above. The Incoming data is decod- 
ed by the codec 310 and routed to a digital-to-analog . 
(D/A) converter 31 2 to produce the output at a speaker 
314. Outbound data to the network 20 originates at a 
mterophone 316 or from an applk;atk>n routine 318. A 
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user can speak into the microphone 316 to communi- 
cate voice data over the data networic 20. Alternatively, 
the application routine 318 (or some other routine) may 
generate voice or other audio data to be transmitted to 
the data networic 20. Examples of this may Include an 
automated answering application, such as a voice mail 
applteation or a voice prompt application from which us- 
ers can select to access to various services. 
[0052] From the microphone, audio signals are 
passed through an analog-to-d!gital (A/D) converter 
320, which digitizes the audio signals and passes the 
digftaf-audio-datano-thecodec-3lt)rTheTroder3T0-^ 
codes the data and transmits the coded data down lay- 
ers 308. 306, 304. and 302 to the data network 20. The 
audio traffic is communicated through the data network 
20 to another terminal to which the termfeial 14. 16. or 
30 has established a call connection. 
[0053] In addition to the audio traffic path, a control 
path exists between the tenminal 14, 16. or 30 and the 
call sender 12 to set up. maintain, and temiinate voice 
calls over the data network 20. In the terminal 14. 16, or 
30 one or more application routines 318 may generate 
control messages that are transmitted to the call server 
12 through the network stack 306, network device driver 
304, networic interface controller 302, and the data net- 
work 20. Control signaling from the call server 1 2 Is s^- 
ilariy received through the same layers from the data 
network 20 back to the one or more applicalton routines 
318. 

[0054] In the call server 12, smiilar layers may exist. 
A network interface controller 330 in the call sender 12 
is coupled to the data network 20. Above the networic 
interface controller 330 is a networic device driver 332 
and a networic stack 334, such as a TCP/IP or UDP/IP 
stack. One or mors call processing routines 336 in the 
call server 1 2 control the management of calls between 
temiinals that are* assigned to the call sewer 12. The 
call processing routines 336 perform the establishment 
of calls, maintenance of calls, and temninatk>n of calls. 
The call processing routines 336 may also periodically 
determine the available usage of the data networic 20, 
which may cause It to update the codec and packet size 
used by the terminals in the vofce communfcatkan ses- 
sion over the data network 20. For example, the call 
sender 12 may maintain a usage table 351 to keep track 
of the number of active telephony calls and the usage 
(based on selected resource elements). 
[0055] fn each tenminal and call sender, various soft- 
ware routines or mcxiules may exist, such as the one or 
nx)re applk^ation routines 318, network stack 306, and 
device driver 304 in the temiinal 14, 16, or 30 and the 
one or more call processing routines 336, network stack 
334, and device driver 332 in the call senrer 12. Instmc- 
tions of such software routines or modules, and others, 
may be stored in storage units 344 and 349 in the ter- 
minal and call server, respectively. The storage units 
344 and 349 may include machine-readable storage 
media fficluding memory devices such as dynamic or 
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static random access memories, erasable and program- 
mable read-only memories (EPROMs), electrically 
erasable and programmable read-only memories (EEP- 
ROMs). and flash memories; magnetic disks sudh as 
fixed, floppy and removable dislcs; ottier magnetic me- 
dia including tape; and optical media such as compact 
discs (CDs) or digital video discs (DVDs). 
[0056] The instructions may be loaded and executed 
by control units 340 and 346 in the terminal and call serv- 
er, respectively, to perform programmed acts. The con- 
trol units 340 and 348 may include microprocessors, ml- 
— crocontTOllers;-applicatlon=specific-integrated-"Circurts'^ 
(ASICs), programnrmble gate arrays (PGAs), or other 
control devices. The terminal 14, 16, or 30 may also In- 
clude a digital signal processor 346 for perfonming arith- 
metic intensive operations such as compression and de- 
compression operations perfomied by the audio codec 
310. 

[0057] The Instructions of the software routines or 
modules may be loaded or transported into a system or 
device in one of many different ways. For example, code 
segments or instmctions stored on floppy disks, CD or 
DVD media, the hard disk, or transported through a net- 
work inteiface card, modem, or other interface mecha- 
nism may be loaded Into the system or device and ex- 
ecuted as corresponding software routines or modules. 
In the k)adlng or transport process, data signals that are 
embodied as earner waves (transmitted over telephone 
lines, network lines, wireless links, cables, and the ilka) 
may communbate the code segments or instructions to 
the system or devk:e. 

[0058] The folbwing discusses the merit-based co- 
dec ranking in accordance with one embodiment A 
modified ranking system may be provided lor packet 
size andAor other resource element selectton. The call 
server 12 maintains a table of characterlstk^s of each 
codec including the following attributes: voice quality 
(Q), bandwWth usage (B). andtenninalDSP(e.g., digital 
signal processor 346 in Fig. 6) resource usage (R). The 
Q, B, and R attributes may contain numeric values 
(ranging between 0 and 1 ). The attribute B In one em- 
bodiment may represent the inverse of the actual band- 
width usage, that is. a higher B value indicates \ow band- 
wkith usage and a low B value indicates high bandwidth 
usage. A higher value of R indicates lower consumptbn 
of DSP resources. The attribute R similarly represents 
the inverse of the actual DSP usage. A merit factor M 
can be computed for each codec in the candidate list as 
a linear combinatk^ of the attributes Q, B, and R ac- 
cording to the following equation: 



sources used for the telephony application. Thus, in one 
example embodiment, the values of the weights Wq, 
Wb. and Wr may be assigned as foflowlng: 

Wq = ( 1 -t) * 0.8. Wb = t, and W^ (1 -t) * 0.2, 



M = WQ*Q + WB*B + Wpj»a 

v(rtiere Wq, Wg, and Wr are weights that are assigned 
to the attributes Q, B, and R, respectively. The values 
of the weights Wq, Wg. and Wr may be dynamic and 
can be based on usage of the pool of transmission re- 



where t is the percentage usage of the pooled transmis- 
sion resources for the telephony appllcatfon. The co- 
10 decs in the candidate list may be arranged in descend- 
ing order of the merit factor M in one embodiment, from 
whtchraxodec-can-tfB-s^electedlorcfSB Inthecall rdb'd" 
established. 

[0059J Thus, according to one embodiment, the merit 
IS factor M Is higher for codecs having relatively high audio 
quality (Q), tow expected bandwidth (e.g.. data transfer 
rate) usage (B), and low expected DSP usage (R). Co- 
decs having relatively tow audio quality, high expected 
bandwidth usage, and high DSP usage will have a lower 
20 M value. Thus, generally, the value of the merit factor 
is increased with higher audio quality and decreased us- 
age of transmisston resources (e.g.. links in the data net- 
work 20 and DSP 346). 

[0060] As noted above, the telephony communication 
2s system 1 0 Includes a network monitor 1 9 for monitoring 
vartous characteristics and conditions of one or more 
portions of the data network 20. Multiple network mor^- 
itors may be present for nnonitortng different portions of 
the data network 20. The characteristics and condittons 
30 monitored Include packet delay, jitter, and percentage 
of packet loss. 

[0061] The network monitor 1 9 may perfonn monitor- 
ing of a network link in a number of different ways. One 
technk:(ue is to use a network monitor having two dlffer- 
35 ent nodes on a networic fink. One node of the network 
monitor can send test packets targeted to the other node 
in the network monitor 19. From the transmission and 
receipt (or lack of receipt) of test packets, the nodes of 
the network monitor 19 can detemfilne the delays in 
"^0 transmissions of packets as well as the percentage of 
packet loss. The network monitor 19 can perrodtoally 
communbate test packets to monitor the link on a peri- 
odic basis. Such a technique may be referred to as a 
static monitoring technk^ue. 
46 [0062] A dynamic technique to monitor a link is to ac- 
cess routers or gateways that communicate with the 
link. Routers and gateways maintain management Infor- 
matton that keep track of delays being experienced with 
links that the routers and gateways are coupled to as 
so well as amounts of packets that are being tost. Thus, 
each time a call sender accesses a networi< monitor to 
request the current cJiaracteristtos and condittons of a 
particular link, the network monitor can issue a query to 
a particular gateway or router to determine the current 
Bs conditions. 

[0083] In further embodiments, the network nrailtor 
19 may also provide end-to-end delay and packet loss 
infomiation based on the several classes of service that 
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may be supported, such as those In a quality-cf -service 
(CXDS) enabled network. For example, If the data net- 
work 20 employs differentrat services (Oiffserv) to pro- 
vide QOS, different classes of packets may be defined 
based on assigned DIffserv code points (DSCPs). One 
class of packets may Include packets delivering voice 
or other audk> data. Other classes may be defined for 
other types of data that may be communbated through 
the data network 20. The different classes of packets 
may be routed through different queues through net- 
work nodes so that higher priority classes of packets are 

deKvered-nwe quickly. TTie-networknr^ 

track the delays and packet loss infonmatton by DSCR 
with one DSCP assigned for the vok:e>over-IP class 
service. 

[0064] Once the packet delay and loss Information is 
determined by the call server 12. the call server 12 can 
access a database of models (referred to as E-models) 
for each call sender to determine if a codec can satisfy 
a desired level of quality based on the prevailing network 
link conditions. E-models (represented in the form of 
charts) may also be maintained for the other resource 
elements. Two E-model charts 350 and 352 are illustrat- 
ed in Figs. 7A and 7B for the Q.729A and Q.723.1 co- 
decs, respectively. Each E-nnodel includes a chart map- 
ping packet delays and percentage of packet toss to a 
desired quality level. In each E-model chart 350 or 352. 
an R value represents the desired quality of senflce. The 
call sender 12 may maintain profiles and policies estab- 
lishing the desired Revalues of calls between different 
combinations of callers. For example, for internal calls 
within an organization, a lower quality of service (and 
therefore lower R value) may be established, whereas 
external calls are set at higher R values. Other embod- 
iments may use different representatkxis of the quality 
of audio sen/ice of codecs and other resource elements. 
[0065] In the chart 350 for the G.729A codec, the hor- 
izontal axis represents packet delay and the vertk:ai axis 
represents the R value. The curves 360A-3601 repre- 
sent different percentages of packet tosses. In one ex- 
ample, the cun^e 360A represents a 0% packet loss, the 
curve 360B represents a 0.5% packet loss, the cun/e 
360C represents a 1% packet loss, the cun^e 360D rep- 
resents a 1 .5% packet loss, the cun^e 360e represents 
a 2% packet loss, the curve 360F represents a 3% pack- 
et toss, the curve 860G represents a 4% packet loss, 
the cun^e 360H represents an 8% packet toss, and the 
curve 3601 represents a 16% packet toss. Thus, as il- 
lustrated In Fig. 7 A, the higher the delay and percentage 
packet loss, the lower the R value. In one embodiment, 
an R value of 90 generally indteates that users are veiy 
satisfied, an R value of 80 generally indicates that users 
are satisfied, an R value of 70 generally indicates that 
some users are dissatisfied, an R value of 60 generally 
indicates that many users are dissatisfied, and an R val- 
ue of 50 and betow generally Indicate that nearly all us- 
ers are dissatisfied with the level of sen^toe. 
[OOeq Thechan352inFig.7BfortheG.723.1 codec 



is similar to the chart 350 in Fig. 7A, with the cunres 
362A-362I representing corresponding percentages of 
packet toss to ounces 360A-360I in Fig. 7A. Thus, given 
the cunrent packet delay and percentage of packet toss, 
s the charts of the E-models for the various codecs may 
be accessed to determine which codec can support the 
desired R value. In further embodiments, different mod- 
els may be used for codec or other resource element 
selection. 

10 [0067] Thus, referring to Fig. 8. in accordance with an 
alternative embodiment thai uses E-model charts, such 
BS-^S0-anti-362,-1hercairs'eiven2TKSelV5ST^t 370)"a"" 
call request from an orlglnatfon termml. The call re- 
quest may Identify the resource elements. Including co- 
15 decs, supported by the originatton terminal. The call 
server can perform (at 371 ) selection of the codecs and 
other resource etoments based on the usage policy and 
usage of transmission resources, including the data net- 
work 20, as descrtoed above In connectton with Figs. 
20 2-5. This may reduce the number of codecs and other 
resource elements. 

[0068] Further, based on the profiles and poltoies as- 
sociated with the Identified orig^ation and destinatton 
temriinals in the call request, the call sender kientifies (at 
^5 372) the target quality of sen^ice (R value). Next, the call 
sen^e r 1 2 can send (at 374) query messages to the net- 
work monitor 1 9 to detennine the current characteristics 
and condittons of the network 20. including network de- 
lay and packet toss. Based on the identified delay and 
^0 packet loss information, the call server 1 2 accesses (at 
376) the E-model charts of the supported codecs. From 
the E-model charts, the call server 12 identifies (at 378) 
the codecs and other resource elements that satisfy the 
target R value. Next, the codecs and other resources 
3S may be ranked (at 380) as described above based on 
various merit attributes to enable selection of one of the 
codecs and other resource elements to use during the 
call, as descrbed above. 

[0069] Some embodiments of the inventton may pro- 
^ vkJe one or more of the foltowing advantages. A flexible 
codec (and other resource element) selection strategy 
Is provided to enforce a policy based on the codec data 
rate between a pair of termfrials where the codec (and 
other resource element) selectton takes Into account the 
^ capacity and resource limitation of the terminals as well 
as network traffic toad and actual transmlsston resource 
usage in each tennlnal. Selection of resource elements 
may also be based on the prevailing characteristics and 
conditions of the networic, such as delay and packet 
so joss. Finepolicycontrolovertelephonytrafficoverada- 
ta networic is made available. Selection may be biased 
towards high voice quality when traffic Is light; however, 
if other network traffic high, then voice quality may be 
reduced to reduce the toad on the data network. 
55 [0070] The codec and other resource element selec- 
tton technique and apparatus may be used with other 
appltoatlons. For example, for video conferencing com- 
munications sesstons over a packet-based data net- 
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work, eelection of video codecs may also be used to re- 
duce load on the data network. 
[0071] Another aspect of managing telephony com- 
munications over a data network Is call admission con- 
trot. A call admission procedure determines whether to 
accept a call request from an orlglnatbn temiinal. If a 
data network, or any portion of the date network, has 
become saturated with traffic (both audio and tradltbnal 
data packet traffic), then further call requests may be 
denied to ensure some predetemiinedquality of service. 
According to one embodiment of the lnventk)n, call ad- 
" ""missions ^s■basod^)n-asage-ofilnks-bBtwsenndifferen^ 
groups of lemiinals (with the groups referred to as com- 
munities). Each community includes multiple teimorials 
that are capable of communicating with each other with- 
out being subjected to call admissions control. This is 
made possible by grouping tenninals that are coupled 
to high capacity links, such as LANs. As used here, a 
community refers to a group of tenninals that are cou- 
pled by links having relatively high bandwkfth. Such ter- 
minals may be located geographically ck38e to each oth- 
er or they may be located over large distances. 
[0072] Within each community, voice calls between 
terminals are allowed to proceed when requested. In 
one embodiment, to provide some limltatkm on band- 
width usage of the oommunk^ation link within each com- 
munity, resource element selection (such as the codec 
and packet size selectbn described above) may be 
used to limit the bandwidth of each call session when 
large numbers of call sessk)ns are present in the com- 
munity. In other embodiments, resource selection may 
be skipped for intra-community calls. The call admission 
control in some embodiments of the invention is provkJ- 
ed for calls made between communities based on usage 
of the links among the communities. 
[0073] Referring to Fig. 9, one arrangement of a voice 
communication system 400 that includes communities 
is Illustrated. The Illustrated multiple links between ter- 
minals are bgical links, not physical links. Ihe logical 
links are part of the overall data network, with e^h link 
corresponding to a path through the data network be- 
tween any two terminals. In Fig. 9, each of the three 
communities 402. 404, and 406 Includes its set of ter- 
minals. In the community 402, terminals 408 are cou- 
pled to a link 409 (e.g., a t^N, WAN, or other network). 
A call sen/er 41 0 Is also coupled to the lin k 409 to man- 
age calls between or among the terminals 408 and be- 
tween one or more of the terminals 408 and a terminal 
external to the conmunity 402. The first community 402 
is coupled to the second community 404 over a link. In 
the second community 404, terminals 414 are coupled 
to an Internal link 415. The second community 404 is 
coupled over another external link 430 to a third com- 
munity 408. An internal link 421 in the community 406 
is connected to temilnal3 420. In the illustrated embod- 
iment, the second and third communities 404 and 406 
share a call sen/er 416. w^ich manages calls wfthin 
each of, or between, the communities 404 and 406 as 



well as between a tenninal in one of the communities 
404 and 406 and another community, such as commu- 
nity 402. Each sen/er maintains a list of its assigned 
communities and terminals in each of those communi- 
^ ties. 

[0074] Generally, the links 430 and 432 (and other ex- 
temal links connecting communities) have tower band- 
widths than the Internal links in each of the communities. 
However, it is contemplated that exceptions to this exist 
10 where an extemal link may have higher bandwidth than 
an Intemal link. For a given community I. the following 
pararTT0ters'7nay-brdeflrted:-|qpwh1ch"represBnts' 
limit on a total available bandwidth between the com- 
munity and a device or system extemal to the commu- 
is nity; M|, which represents the threshold at which rese- 
lection of a codec, packet size, or other resource ele- 
ment is performed to reduce bad on a link In a commu- 
nity; N,, which represents a threshoW to restrict outgohg 
calls; and T|, which represents the usage of the trans- 
so mission resources in the community. 

[007S] Thus, according to one embodiment of a call 
admission control, outgoing new call requests from the 
community I may be denied if the value of T, exceeds 
the threshold N|. If the traffic T| exceeds the threshoM 
M,, Oien the call sen/er for the community I can start to 
perform codec and other resource selection to reduce 
traffic. Thus, as described above in connection with 
Figs. 2-5. a call sen/er may discard codecs andAor other 
resource elements based on transmlsston resources 
50 that the call server monitors, including the several 
thresholds L|, M|, and N|Of the community I. In one em- 
bodiment, the value of M| is about 60% to 80% of Lj. The 
value of N| can be set at a value closer to or at Lj. 
[0076] Further, a pair-wise limit can be added for call 
3S admission control between communities, in thfe embod- 
iment, for a given community link between two commu- 
nities I and J, the following parameters may be defined: 
Ly , which represents the limit on a total bandwidth to be 
used by the community link IJ for the telephony applica- 
40 tion; My, which represents the threshold at which re- 
source element selection Is perfonned; and Tjj. which 
represents the usage of transmission resources dl the 
conrvnunity link kJ. A community link does not have an 
N parameter since a link has no direction and the con- 
45 cept of incoming or outgoing calls does not apply. 
[0077] For a terminal In community I to establish a 
new call with a temiinal in community J, the following 
must be satisfied: 



so 



T, <N|andTy <Ly. 



[0078] The first clause essentially states that the traf- 
fic between community I and all other communities must 
ss be less than the ihneshoW limit N,. The value of T, is the 
sum of all traffic between community I and all other com- 
munities, that is 
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[OO70J The second clause (Ty < Ly) specifies that the 
traffic on the link IJ between communities I and J must 
be less than the threshold L^j. If either of the two clauses 
are not satisfied, then the call request from a terminal In 
community I is denied. A threshold Mjj is also specified 
for the link IJ between communities I and J to specify a 

— Jimitat which fesource-selectionis-perfomf^edr 

10080] The limits L,, Ly. M,. and M|,j may be static 
(that is. they remain fixed) or adaptive (that Is, they may 
change with changing conditions of the data network). 
For example, as the data network traffic increases, the 
threshold values may decrease. The call sen/er can col* 
lect statlstbs regarding the network (such as by access- 
ing a networic monitor or other node such as a router or 
gateway) to determine the conditfons of the network. 
Based on the conditions, e.g., large delays or packet 
losses, the threshold values may be decreased to main- 
tain high quality of service. 

£0081] As INustraled In Fig. 9, the first community 402 
has the following parameters: T^ , L, . , ; the second 
community 404 has the following parameters: Tar L2, 
Mg, and Na; and the third community 406 has the folk>w- 
Ing parameters: T3, M3. and Ng. The community link 
432 has the follow&ig parameters: T^^. ha* ^12; andthe 
community link 430 has the following parameters: T23. 

L23i €Uld M23. 

£0082] Refemng to Figs. 10A-10B, the call admis- 
sions control procedure is illustrated for a call between 
an originatbn terminal in one community (community I) 
anda destinatkm terminal in asecondcommunity (com- 
munity J). In the example of Figs. 10A-10B. a first call 
sender 500 sen^ices community I and a second call serv- 
er 501 services community J. The call sender 500 re- 
ceives a CalLSetup message from a terminal in com- 
munity I that Includes a list of supported audk> codecs 
and a list of supported packet sizes. The call server 500 
then determines (at 502) whether the caO is an intra- 
community or an inter-communtty call. If the call is an 
intra-communlty call, then the call server 500 In commu- 
nity I performs intra-community call processing and ex- 
changes messages between the terminals involved in 
the call ses6k)n (at 504). Codec and other resource el- 
ement selection may be performed as described above 
if the traffic T| exceeds the threshoW value M,. 
[0083] If the call Is an inter-community call, then the 
call server 500 detenmines (at 506) the name of the orig- 
ination community, in this case community I. The call 
sewer 500 then checks the attributes L|, and N, of 
the community I. At this point, the call server 500 checks 
the traffic T| (between community I and all other com- 
munities) against the limit N|. If T, exceeds Nf, then the 
call is denied by the call sender 500. However, if the call 
request is allowed to proceed, then a candidate list of 



codecs and packet sizes is then created. Such a list of 
codecs and packet sizes may be further restricted based 
on the values of the thresholds L,, M|. and N,. The band- 
width for community I Is reserved to resen^e capacity for 
5 the requested call. This allows the call sender 500 to 
monitor the available bandwidth for further inter-com- 
munity call requests from terminals in the community I. 
[0084] A call request message Is sent (at 508) frbm 
the call server 500 to the call server 501 that is assigned 
10 to community J. The message includes the name of the 
origination community I as well as the candidate list of 
codecyantf7?ac1cet"8teBsr1 i ri esponse to t h e m aee a gg - 
from the call server 500, the call sen/er 501 determines 
the destination community name J, the community link 
15 ij, and checks the limits Lj. Mj, and Nj. L|j and Mjj (at 
510). Such a check includes checking if value of T|j ex- 
ceeds L,j. Also, the value of Tj (total traffte of inter-com- 
munity calls between community J and all other commu- 
nities) is evaluated against Lj. If Tj exceeds Lj or Ty 
20 exceeds Ljj, then the call is denied and the call sender 
501 infonns the call server 600 of the call termination. 
The call sender 601 may also check T|j against My. and 
Tj (total traffic from community J) against Mj, to deter- 
mine if resource selection is needed. 
25 [0085] From the limits, the call server 501 may further 
restrict the list of allowed codecs and packet sizes. 
BandwkJth is then resented for the community J and link 
IJ for the requested call. The call sewer 501 then sends 
a CalLSetup message (at 512) to the destination tenni- 
30 nal in community J. The CalLSetup message includes 
the codec and packet size candidate list In response to 
the CalLSetup message, the destlnatk)n temiinal sends 
back a CalLConnect message (at 514) that identifies a 
selected codec and a packet size. The call sewer 501 
35 and destination tenninal may select a codec and packet 
size using techniques described inconnection with Figs. 
2-5. which uses a ranking algorithm. Based on the re- 
turned CalLConnect message kJentlfying the selected 
codec and packet size, the call sewer 501 corrects (at 
^ 51 6) the expected bandwidth usage of community I and 
link IJ. The call sewer 601 then sends back (at 518) a 
Connect/Answer message to the call sewer 500 that in- 
cludes an identification of the temiinatfon community 
link (J) and the selected codec and packet size. Based 
^5 on the Identification of the selected codec and packet 
size, the expected bandwidth usage in the community I 
for the call session Is corrected, and the expected band- 
width usage of the community link I J is updated (at 520). 
[0086] At this point, a call has been connected be- 
50 tween the origination tenmlnal and the destination termi- 
nal in communities I and J, respectively. If the originatton 
temiinal desires to terminate the phone call, then if 
sends a release message (at 622) to the call sewer 500. 
In response, the call sewer 501 updates (at 530) its 
5$ bandwidth usage of community I and flnk IJ and sends 
a release message (at 524) to the call sewer 501. In 
response to the release message, the call sewer 501 
updates (at 526) the bandwidth usage for community J 
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and link IJ to reflect tenmlnation of the call. The call serv- 
er 501 sends a release complete message (at 528) to 
the destination call server to terminate the call. 
[0087] In some cases, it is easy to determine whether 
or not a call is intra-communrty or rnter-community. For s 
example, the translation component in a call sender can 
be equipped with information indicating whether or not 
the call request is for an intra-community caO. However, 
in some other cases, the origination terminafs call serv- 
er cannot accurately detemnine if a call request is for an io 
Intra- or intercommunity call. For example, although a 
'xallTeqDestTnayideiitify adesllnalion termlrialin'Hnoth= 
er community, the destination terminal may have for- 
warded the call back to a temfiinal in the origlnatbn com- 
munity. In this case, the originatkxi tenfninal's call sender 75 
may assume that the call Is an inter-community call and 
delete any codecs and other resource elements from the 
candidate list teased on the originatton temninai's com- 
munity threshold values. IHowever. the call may still be 
determined to be an intra-community call by a second 20 
call sender associated with the assumed deetir^ion ter- 
minal. The second call sender may determine that the 
call has been forwarded tiack to the community of the 
origination temiinal. Thus, in an embodiment in which 
intia-community calls are not subject to resource ele- 2S 
ment selection, the call request should not be denied 
even if the resulting candidate list is empty since the call 
may be lonivarded back to the origlnatbn temnlnars 
community for an intra-community call. However, if the 
call is indeed inter-community, and the candidate codec 30 
list is empty, then the call Is denied by the second call 
server. 

[0088] A cal I management method and apparatus has 
been described to offer call admissions control and se- 
lection of resource elements to more effectively manage 3$ 
usage of a data network for telephony communicattons 
while providing a higher quality of senrlce. 
[0089] Whif e the inventbn has been discbsed with re- 
spect to a iimited number of embodiments, those skilled 
in the art wiU appreciate numerous modlficatbns and ^0 
variations therefrom. It is Intended that the appended 
claims coverall such modifications and variatbns as fall 
wfthin the true spirit and scope of the rivention. 

4S 

Claims 



ed call in response to the call request t>ased on 
usage infomiation of the data network. 

2. The method of claim 1, wherein the selecting in- 
cludes selecting one or more resource elements 
based on usage polk::y set by a policy server. 

3, The method of claim 1, wherein the selecting in- 
cludes selecting one or more resource elements 
based on actual usage of the data network. 

"4; - Th'firmethodt)tncte(lni T,~whWBrn-tKe-§me^^ — 
eludes selecting one or more codecs as candkiates 
for use in each network terminal. 

5. The method of claim 1, wherein the selecting in- 
cludes selecting one or more sizes of a packet as 
candidates for cariying audio data in the requested 
can. 

6. Themethodof claim l.furthereelectingoneormore 
of the plurality of resource elements based on sup- 
port for the one or more resource elements in each 
of the at least two network terminals. 

7. The method of claim 1, further comprising ranking 
the resource elements according to merit based on 
quality of the requested call and expected band- 
width usage of the data network. 

8. The nrtethod of claim 7, wherein the ranking of the 
resource elements is further based on expected us- 
age of a digital signal processing element of each 
terminal. 

9. The method of claim 1 , further comprising determin- 
ing a condition of the data network, wherein the se- 
lecting is further based on the determinedconditlon. 

10. The method of claim 9, wherein the detemnining in- 
cludes detennming a delay in the transmisskm of 
packets in the data network. 

11. The method of claim 9, wherein the determining in- 
cludes detenmming a percentage of packet loss in 
the data network. 



1. A nr^thod of managing calls over a data network, 
comprising: 

60 

determining usage information of the data net- 
work; 

receiving a call request for establishing a call 
between at least two network temilnals; and ss 

selecting one or more of a plurality of resource 
elements as candidates for use in the request- 



12. The method of claim 9, further comprising determin- 
ing an expected quality of sen^ice based on the de- 
temnined conditk>n of the data networtc 

13. The method of claim 1 , further comprising perform- 
ing call admissions control to accept or deny the call 
request 

14. The method of claim 13, wherein perfomilng call ad- 
missions control is based on usage of a link in the 
data network between groups of terminals. 
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16. The method of claim 13, wherein the at least two 
temiinais are defrned in at least two communities 
coupled by a link, and wherein performing call ad- 
missions control includes perfomfilng call admis- 
sions control based on a threshold set for the link 
between the communities. 

1 6. The method of claim 1 5, further comprising bypass- 
ing the call admissions control within each commu- 
nity. 

"-17r-The-method oft:laim-l 6; wherein -selecting one or 
more resource elements Is performed in each conv 
munity. 

18. A sen/er for managing calls in a system having a 
network, comprising: 

an interface to the network to receive a call re- 
quest to establish a call between two endpoints 
on the network; and 
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27. The sewer of claim 24. wherein the control unit is 
adapted to present the ranked resource elements 
to at least one of the endpoints for the at least one 
endpoint to select a resource element. 

28. A computer program product capable of running in 
a system so that the system so programmed carries 
out a method including: 

receiving a call request containing information 
identifying an origination endpoint, a destlna- 

ndpolfit, ctnd ohe or more resoijrce~^e- " 
ments supported by the origtnatkxi endpofnt; 

seleclrig one or more of the one or more re- 
source elements based on perceived audio 
quality and usage of a data network; and 

presenting the selected one or more resource 
elements as available for use in a call between 
endpointG. 



a control unit adapted to process the call re- 
quest and to control selectfon of one of a plu- 
rality of resource elements to be employed by 
the endtx>hts in the call. 

19. The sender of claim 18, wherein the control unit is 
adapted to retrieve information regarding usage of 
the network, the control unit controlling selection of 
the one resource element based on the usage. 

20. The server of claim 18, wherein the resource ele- 
ments include codecs to be empbyed by the end- 
points in the call. 

21. The server of claim IB, wherein the resource ele- 
ments include sizes of messages to be used for car- 
rying audio data In the call. 

22. The server of claim 21 , wherein the sizes of mes- 
sages are determined by a selected number of 
frames carrying audio data in each message. 

23. The server of claim 1 8, wherein the calls include te- 
lephony calls. 



29. A method of nnanaging calls In a telephony system, 
comprising: 

2S 

defining a plurality of communities each Includ- 
ing one or more connmunteatlon endpoints; 

assigning one or more usage threshokl values 
30 to a link between communities; and 

processing a call request based on the one or 
more usage threshoki values, 

^ wherein the processing includes detenrnining 

whether to admit the call request over the link. 

30. The method of claim 29, wherein the processing fur- 
ther includes selecting one or more resource ele- 

40 ments to be used during a call between endpoints 
over the link. 

31. The method of claim 29, wherein the assigning In- 
cludes assigning a threshold value indk:atrng the 

^ available bandwidth on the link between the com- 
munities. 



24. The senrer of claim 18, wherein the control unit is 
adapted to rank the resource elements by one or 
more predetenmined criteria. 

25. The sen/er of claim 24, wherein the control unit is 
adapted to select the resource element having a 
highest relative rank. . 

26. The server of claim 25, wherein the control unit is 
adapted to detennlne resource elements supported 
by the endpoints. 



32. The method of claim 29. wherein the processing fur- 
ther includes selecting one or more resource ele- 
ments to be used during a call between endpoints 
over the link, and wherein the assigning Includes 
assigning a usage threshokl value over which the 
selecting Is to be performed 

33, The method of claim 29, wherein the assigning in- 
cludes assigning a usage threshoki value oyer 
which further outgoing calls from a community is 
prohibited. 



so 
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34. A call establishment method, comprising: 

determining a candidate list of coding resource 
members associated with a call request; 

s 

checking a usage policy for the call request; 

removing from the candidate list a first set of 
coding resource members whose bandwidth 
requirements exceed the usage policy; io 

ranidng-a-second-setaTXxlingTesourcermem= 

bers of the candidate list according to merit, the 
second set being district from the first set; 

IS 

selecting from the second set ot coding re- 
source member having a highest relative merit; 
and 

establishing a call specified by the call request 20 
using the selected coding resource member. 

36. The call establishment method of claim 34. wherein 
the determining includes: 

25 

receiving at least one supported coding re- 
source of an endpoint specified with the call re- 
quest; and 

assembling the candidate list from the at least ^ 
one received supported coding resource. 

36. The call establishment method of claim 35, wherein 
the call request specifies an originating endpoint 
and at least one destination endpoint; and 3S 

wherein the receiving comprises receiving at 
least one supported coding resource member for 
each of the originating and at least one destination 
en(4>oint8. 

40 

37. The call establishment of claim 34, wherein the 
ranking comprises ranking the second set of coding 
resource members according to at least one of per- 
ceived voice quality, bandwidth usage, and end- 
point digital signal processing resource usage. 

38. The call establishment method of claim 34, wherein 
the call establishing ^Is to establish the call when 
the second set is empty. 

so 

dd. A call server, comprising: 

means for determinrig usage Information of the 
data network; 

55 

means for receiving a call request for estabGsh- 
Ing a call between at least two network temit- 
neUs; and 



means for selecting one or more of a plurality 
of resource elements as candidates for use in 
the requested ca9 in response to the call re- 
quest based on usage Infonnatton of the data 
network. 
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a plurality of communities (402, 404, 406) may be de- 
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